Skip to content

[go-migration] Update sapmachine versions#1141

Merged
ramonskie merged 3 commits intocloudfoundry:feature/go-migrationfrom
kiril-keranov:patch-3
Jan 14, 2026
Merged

[go-migration] Update sapmachine versions#1141
ramonskie merged 3 commits intocloudfoundry:feature/go-migrationfrom
kiril-keranov:patch-3

Conversation

@kiril-keranov
Copy link
Contributor

@kiril-keranov kiril-keranov commented Jan 13, 2026

  • Added SapMachine 25 to the go migrated community buildpack
  • Added SapMachine 21 to the go migrated community buildpack
  • Removed SapMachine 11 which is EOL since some time
  • Make 21 the default version for SapMachine as 17 is EOL September this year

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Jan 13, 2026

CLA Signed

The committers listed above are authorized under a signed CLA.

version: 17.0.17
uri: https://github.com/SAP/SapMachine/releases/download/sapmachine-17.0.17/sapmachine-jre-17.0.17_linux-x64_bin.tar.gz
sha256: c45d572629c722b18a6254f7503a397dbfe474223afb3ac96ef462d27074f7a0
cf_stacks:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my understanding: Are these (exact) versions only for testing or will they have to be updated every time new SapMachine builds are made available?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RealCLanger I think these are the versions that will be used productively and should be subject of regular update. Note that the current community java buildpack is the only one written in Ruby, all the rest community buildpacks follow the same structure, for example python buildpack. @ramonskie please correct me if wrong

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are correct.
the pattern should be for each java-buildpack version should have x version. this way you can always revert if necessary. how the old java buildpack handled versioning was totally different from all the other buildpacks.
that said. we should create ci automation to update the versions regularly. we already do that for all the other buildpacks anyways. where currently prs will be created for reviews and for major version bumps a issue wil be created.
so it requires a bit more of manual work

Copy link
Contributor

@ramonskie ramonskie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@ramonskie ramonskie merged commit 70faf51 into cloudfoundry:feature/go-migration Jan 14, 2026
1 check passed
@kiril-keranov kiril-keranov changed the title Update sapmachine versions [go-migration] Update sapmachine versions Jan 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants